<?xml version="1.0" ?>
<!DOCTYPE html 
  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>DeepConnect</title>
</head>
<body>
<h1><a name="label-0" id="label-0">["分散オブジェクト環境 DeepConnect 入門"]</a></h1><!-- RDLabel: "分散オブジェクト環境 DeepConnect 入門" -->
<h2><a name="label-1" id="label-1">["DeepConnect とは?"]</a></h2><!-- RDLabel: "DeepConnect とは?" -->
<p>DeepConnectは, 分散オブジェクト環境を実現するためのフレームワークであ
る.</p>
<p>fairyで採用されている.</p>
<h2><a name="label-2" id="label-2">["DeepConnect って何をしてくれるの?"]</a></h2><!-- RDLabel: "DeepConnect って何をしてくれるの?" -->
<p>ネットワーク越し, または、別のプロセス空間上のオブジェクトに対し,
メッセージを送り, 実行し, その結果を得ることができる機能を提供する.</p>
<p>シンタックスを重視し, Rubyのメッセージ形式をそのまま利用できる.</p>
<ul>
<li>remote_obj.message(arg1,...)</li>
<li>remote_obj.message(arg2, ...){...}</li>
</ul>
<p>もっと分かりやすく言えば、drb と考え方は似ている. </p>
<h2><a name="label-3" id="label-3">["歴史"]</a></h2><!-- RDLabel: "歴史" -->
<ul>
<li>1996.11.18 [ruby-list: 1361] で初投稿</li>
<li>1997.01.31 [ruby-list: 2009] が最後の投稿
<ul>
<li>たぶん、モチベーションが下がった...</li>
</ul></li>
<li>1999.07.14 drb 登場
<ul>
<li>そのころソースをいじった形跡があるので、少しやる気が出たらしい (^^;;</li>
</ul></li>
<li>2001.06 ごろ 別のコンセプトでまた考えている</li>
<li>2008.06.22 fairy で適用開始
<ul>
<li>DeepConnect と命名</li>
<li>ほとんど修正なしで動作. たぶん, 1999年の時点で動作していたのだろう。</li>
</ul></li>
<li>2010.10.22 githubに公開</li>
<li>2010.10.28 rubygems.org に公開</li>
</ul>
<h2><a name="label-4" id="label-4">["DeepConnect入門 - イメージ"]</a></h2><!-- RDLabel: "DeepConnect入門 - イメージ" -->
<p>(作業中)</p>
<h2><a name="label-5" id="label-5">["DeepConnect入門"]</a></h2><!-- RDLabel: "DeepConnect入門" -->
<p>サーバー側(受けて側)は以下のように書く:</p>
<pre>dc = DeepConnect::start(port)	  
# サービス開始
dc.export("name", obj)	  
# obj を name で参照できるように宣言
dc.export("RemoteArray", Array) 
# クラスでもexportできる</pre>
<p>クライアント側(リクエスト出す側)は以下のようになる:</p>
<pre>dc = DeepConnect::start
ds = dc.open_deepspace(相手addr, 相手port)
# 相手(のDeepSpace)と接続</pre>
<p>DeepSpaceは, 接続相手のオブジェクト空間を意味している. 相手側でexport
したオブジェクトをimportすることができる. </p>
<pre>remote_obj = ds.import("name")
# リモートオブジェクト(の参照)を取得. 取っ掛かりのオブジェクトはimportする必要がある
RemoteArray = deepspace.import("RemoteArray")
# クラス(の参照)も同様に取得可能</pre>
<p>あとは、だいたい普通にRubyのプログラムを組めばよい:</p>
<pre>ret = remote_obj.req
# 戻り値もリモートオブジェクト(の参照)
remote_ary = RemoteArray.new
# サーバー側で配列が作られる。そのオブジェクト(の参照)を取得
remote_ary.push "foo"
# さらにリモートオブジェクトにメッセージを送ることが可能</pre>
<h2><a name="label-6" id="label-6">["特徴"]</a></h2><!-- RDLabel: "特徴" -->
<p>DeepConnectの特徴は以下にあげられる:</p>
<ul>
<li>メソッドは参照渡し</li>
<li>メソッドスペック</li>
<li>Future型</li>
<li>分散GC</li>
<li>自動接続</li>
<li>ShallowConnectモード </li>
</ul>
<h2><a name="label-7" id="label-7">["特徴 - メソッドは参照渡し"]</a></h2><!-- RDLabel: "特徴 - メソッドは参照渡し" -->
<p>メソッドは参照渡しという意味は, メソッドの引数も戻り値も参照渡しになる
と言うことを意味する. これは, オブジェクト指向システムでは当たり前のこ
とである. オブジェクト指向では, オブジェクトのアイデンティティが重要で
あり, 何の考えもなくオブジェクトのコピーを渡すことはすることは持っての
ほかと言える.</p>
<p>リモートオブジェクトとローカルのオブジェクトを区別なく利用可能になるた
め, オブジェクトの参照渡しを基本とすることによって, 既存プログラムの分
散化が簡単に実現可能になる. 値(コピー)渡しではそのようなことは不可能
である.</p>
<p>どのオブジェクトをどこに置くかを考えるだけでよくなる. つまり, モデリン
グにおける論理モデルと配置モデルとの分離が可能にある</p>
<p>例:  fairyのmapの実装</p>
<pre>def basic_each(&amp;block)
  @map_proc =BBlock.new(@block_source, @context, self)
  @input.each do |e|
    block.call @map_proc.yield(e)
  end
end</pre>
<p>上記の例の場合, @inputが前段のフィルタになっている。これが、リモートの
オブジェクトの場合もあるし、ローカルのオブジェクトの可能性もある。</p>
<p>このように、リモート/ローカルのオブジェクトを区別なく扱えるようになる
ことにより、オブジェクトの分散配置が自由に行えるようになる。これには、
クラスをexportできるのが有効</p>
<h2><a name="label-8" id="label-8">["特徴 - メソッドは参照渡しとはいっても"]</a></h2><!-- RDLabel: "特徴 - メソッドは参照渡しとはいっても" -->
<p>ただし、以下のものは値(コピー)渡しになっている</p>
<ul>
<li>Immutable なもの</li>
<li>String </li>
</ul>
<p>Stringに関しては, パフォーマンスの考慮しこういう選択になった. 文字列の
場合、オブジェクトとして扱うよりは値がほしいことが多いので、実用上はほ
ぼ問題がない.</p>
<p>さらに, その他のオブジェクトでも, オブジェクトとしてよりも, その値がほ
しい場合, パフォーマンスを考えると値(コピー)渡しにしたいこともありえる.</p>
<p>また,  組み込みのメソッドの中には参照では困ることが多い.</p>
<p>例えば, Array#&amp; の</p>
<pre>remote_ary &amp; ary</pre>
<p>このばあい、Array#&amp; の実装はaryをローカルなオブジェクトとして理解し,
リモートオブジェクトとして扱ってくれない. </p>
<h2><a name="label-9" id="label-9">["特徴 - メソッドスペック"]</a></h2><!-- RDLabel: "特徴 - メソッドスペック" -->
<p>メソッドに対し、MethodSpecを指定することにより上記の問題を回避している.
メソッド単位で参照以外を渡すことも可能になる。指定できるのは3種:</p>
<ul>
<li>REF  - 参照</li>
<li>VAL  - シャローコピー</li>
<li>DVAL - ディープコピー</li>
</ul>
<p>メソッド引数、戻り値、ブロック引数、ブロック戻り値に指定可能になっている.</p>
<pre>DeepConnect.def_method_spec(Object, "VAL to_a()")
DeepConnect.def_method_spec(Array, :method =&gt; :==, :args =&gt; "VAL")</pre>
<p>組み込みメソッドに関しては、一通り定義済みになっていて, 前述の Array#&amp; 
のような問題は解消している.</p>
<p>実際には, クラス単位での指定も出来るが、MethodSpecを使うほうが便利だ.</p>
<h2><a name="label-10" id="label-10">["特徴 - Future型"]</a></h2><!-- RDLabel: "特徴 - Future型" -->
<p>非同期通信を実現するための手段として採用した. </p>
<p>メッセージを送った後、そのメッセージの結果を待たずに、実行を継続し、実
際に必要になったときに、値があればそれを使い、なければ値が帰るまでまつ。</p>
<pre>v = DeepConnect::future{remote.req}
# 処理を継続、vがFutureオブジェクト
v.value			
# 実際の値の取得
v.messege		
# Delegatorにもなっている</pre>
<h2><a name="label-11" id="label-11">["特徴 - 分散GC"]</a></h2><!-- RDLabel: "特徴 - 分散GC" -->
<p>他から参照されているオブジェクトは、GCされないようにしている。</p>
<p>参照されなくなったら、GCの対象となるようになっている</p>
<p>リファレンスカウント方式の分散GCを備えている。</p>
<ul>
<li>完全なGCではないのでごみが残ることもある。</li>
<li>かわりに、明示的なリリースメソッドを用意している</li>
</ul>
<h2><a name="label-12" id="label-12">["特徴 - 自動的な接続"]</a></h2><!-- RDLabel: "特徴 - 自動的な接続" -->
<p>必要があれば、自動的に接続する.</p>
<p>最初の取っ掛かりは、明示的接続が必要となる.</p>
<pre>ds = dc.open_deepspace(相手addr, 相手port)
remote_obj = deepspace.import("name")</pre>
<p>接続のされていない空間のオブジェクトの参照が渡されると自動的にその空間
と接続するようになっている。</p>
<pre>remote_obj2 = remote_obj.other_deepspace_opj</pre>
<p>複数プロセス間で参照のやり取りがある場合非常に便利になる.</p>
<h2><a name="label-13" id="label-13">["特徴 - ShallowConnect モード"]</a></h2><!-- RDLabel: "特徴 - ShallowConnect モード" -->
<p>DeepConnectは、接続先に対してどんなメソッドも呼び出せてしまう。その特
性から, DeepConnectの名前の由来になっている. ただし, これはこれで、便
利だが、信頼できない相手とのやり取りは危険となる.</p>
<p>そこで, CORBA IDL的な指定ができるモードを用意した. ShallowConnectモー
ドでは, インターフェース宣言されたメソッドだけを利用可能に出来ようにな
る. ただし、すべて宣言しなくてはならないので、かなり面倒</p>
<h2><a name="label-14" id="label-14">["アーキテクチャ"]</a></h2><!-- RDLabel: "アーキテクチャ" -->
<p>(作業中)</p>
<h2><a name="label-15" id="label-15">["実績"]</a></h2><!-- RDLabel: "実績" -->
<p>fairyで採用されている. fairy自身はかなり激しい分散並列処理システムでヘ
ビーユーザーさまです. おかげさまで DeepConnect の品質が向上しました(^^;;</p>
<p>fairyローカル版から、fairy分散版への修正は、5%ぐらいの修正で動作した.
その修正も, ほんとんどがオブジェクトのexport/importの指定ぐらい.</p>
<h2><a name="label-16" id="label-16">["注意事項"]</a></h2><!-- RDLabel: "注意事項" -->
<p>あまりにも分散を無意識にできてしまうので、注意も必要である.  </p>
<p>構文上同じでも、ネットワーク通信はやっぱりコストがかかる。したがって, 
パフォーマンスのことを考えると, あまりプロセス間通信が発生しないように
細かいメッセージは集約をしたり, 順番を入れ替える必要がある.</p>
<p>不用意な戻り値の問題. Rubyでは, 全てのメソッドに戻り値がある. また, ブ
ロックの実行にも戻り値がある. Rubyで普段プログラミングする上では, 戻り
値を利用しない場合, それをそのまま捨てる(代入しない)ければ, それで済む
が, DeepConnectの場合, 常に戻り値がネットワークを越えて渡ることになる.
これが, パフォーマンスを悪くする要因になりうる. </p>
<p>Array も参照が渡される. Rubyを理解していれば、だいじょうぶなはずだが、
時々忘れることもある. </p>
<p>参照に対する == は、equal? になっている。Hash等でパフォーマンス上問題
になるため。このようになっている.</p>

</body>
</html>
